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Sir: 

Appellant, having filed a timely Notice of Appeal of a Final Office Action in the 
above-identified patent application, hereby submits this Appeal Brief in support of 
patentability. 



I. REAL PARTY IN INTEREST 



The present application is assigned to Epic Systems Corporation as evidenced 
by the assignment recorded by the United States Patent and Trademark Office on May 
17, 2002 at Reel/Frame 012912/0063. 



II. RELATED APPEALS AND INTERFERENCES 
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There are no related appeals or interferences. 

III. STATUS OF CLAIMS 

Claims 1-8 and 14-20 are pending in the present application. Claims 1-8 and 14- 
20 have been finally rejected under 35 U.S.C. §1 03(a). The rejections of each of claims 
1-8 and 14-20 are being appealed. 

IV. STATUS OF AMENDMENTS 

Amendments prior to the final office action have been entered. No amendments 
were attempted after the final rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Claim 1 and claims that depend there from are drawn to a system for distributed 
computing that includes a clinical exchange server that is programmed to do three 
things. First, the exchange server is programmed to maintain a patient identification 
cross reference table that includes a list of applications and patient identification 
numbers used by each application where the patient identification numbers are 
application distinct. Second, the exchange server is programmed to maintain a list of 
events reported to it by the applications. Third, the server is programmed to respond to 
queries from a first application about an event recorded by a second application by 
transmitting a query to the second application based on the information in the reference 
table and the list of reported events. Claim 19 is system claim similar to claim 1. Claim 
14 is a method claim similar to claim 1 . 

QB\8282042.1 



Carl Dvorak 

Serial No.: 10/052,659 
APPEAL BRIEF 
Page 3 

Claim 5 is drawn to a computer network comprising a clinical exchange server 
programmed to store in a storage device a reference table including a master patient 
identifier for each patient, a list of application programs, and any separate identifying 
code used for the patient by any of the application programs wherein the identifying 
codes are application specific patient identifying codes for the patient so that the 
identifying code used by an application for a patient can be found by accessing the 
reference table. Here, the clinical exchange server is also programmed to facilitate 
information exchange between the applications by using the reference table to extract 
information from one application that is requested by another application. Claim 18 is a 
method claim similar to claim 5. 

Claim 20 is drawn to a system for distributed computing comprising a computer 
network and first and second application run on the network that uses first and second 
different patient identification numbers to reference a first patient, respectively and a 
clinical exchange server programmed to perform two functions. First, the exchange 
server is programmed to maintain a patient identification cross reference table including 
a list of applications on the network including the first and second applications and 
patient identification numbers used by each application. Second, the exchange server 
is programmed to respond to inquiries from the first application about an event recorded 
by the second application by transmitting a query to the second application based on 
the information in the reference table. Thus, claim 20 is similar to claim 1 except that 
claim 20 does not require that the server maintain a list of events reported by 
applications and does not use the list of events to generate the query to the second 
application. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

In the final Office Action dated April 24, 2009, claims 1-8 and 14-20 were rejected 
under 35 USC § 103(a) as being unpatentable over Morange (US patent application No. 
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2005/0102374) in view of Felsher (US patent application No. 2002/0010679) and further 
in view of Smithies (US patent No. 5,544,255). 

VII. ARGUMENT 

The burden of establishing a prima facie case of obviousness falls on the 
Examiner. MPEP § 2142 . A prima facie case of obviousness under 35 U.S.C. § 103 
requires, at a minimum, that the Examiner provide a clear articulation as to why the 
claimed invention would have been obvious to one of ordinary skill in the art. MPEP § 
2142. Rejections on obviousness cannot be sustained by mere conclusory statements. 
Instead, there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness. MPEP § 2142.01 IV . 

Claims 1-4 were rejected under 35 USC § 103(a) as being unpatentable over 
Morange (US patent application No. 2005/0102374) in view of Felsher (US patent 
application No. 2002/0010679) and further in view of Smithies (US patent No. 
5,544,255). 

First, with respect to claim 1 , claim 1 requires, among other things, a cross 
reference table that includes a list of applications on a network and distinct patient 
identification numbers for each of at least two of the applications on the list and using 
information from the reference table to generate a second guery to a second 
application. 

Neither Morange nor Felsher teach or suggest applications that use different 
patient identifiers for the same patient as correctly recognized in the most recent Office 
Action. 

However, despite contrary assertions in the Office Action, neither Morange nor 
Felsher teach or suggest several other steps required by claim 1 . First, neither Felsher 
nor Morange teaches a reference table that stores a list of applications and identification 
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numbers used by the applications. The sections of Felsher cited as teaching this 
limitation simply do not. More specifically, paragraph 266 teaches that transactions 
(i.e., data in a record that is related to a medical event such as a blood test, radiological 
data, an admission record, etc. - see paragraph 267)) for a single patient are all 
indexed using a single unique patient identifier (e.g., an SS number), paragraph 267 
teaches that metadata associated with and rules for accessing transaction records are 
stored outside the records to facilitate access thereto, paragraph 268 teaches that 
records may comprise a subset of files that are distributed and indexed and none of the 
cited paragraphs teaches or suggests a table listing applications and associated patient 
identifiers and paragraph 279 teaches that one system architecture includes databases 
of records, an index relating patient IDs to database records and a certification 
authority. 

Second, while Felsher may contemplate a system that includes multiple 
applications, Felsher clearly does not teach or suggest that a second query is generated 
for a second application in response to reception of a first query at an exchange server. 
To this end, Felsher teaches a system that includes a custodian medical record system 
that renders records related to medical transactions (see paragraph 264) available to 
different applications. To this end, as records are created, the records are stored. 
Records may be stored with the custodian medical record system or, in the alternative, 
in other locations as part of a distributed database (see paragraph 268). Where records 
are stored in a distributed database, Felsher teaches that a central index is maintained 
by the custodian medical record system which records, for each patient, the location of 
the record (i.e., the transaction) along with access rules (e.g., metadata and access 
rules - see paragraphs 267 and 268). 

Where a second application creates and stores a record and the location of that 
record is indexed by the custodian system, when the stored record is subsequently 
required by a first application, a single query is provided to the custodian system (see 
paragraph 264) and the custodian system can use the index to directly access the 
record in the database . Thus, because Felsher contemplates a system wherein the 
custodian system can directly access a required record, there is no reason for the 
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custodian system to generate a second query to be provided to the second application. 
In short, Felsher simply teaches a distributed database where a custodian system 
indexes records for patients so that applications that generate the records do not have 
to be employed after record storage to access the records. 

Third, even if it were determined that Felsher teaches a system where a server 
generates a second query to a second application, the second query taught in Felsher 
is the same as the first query and therefore there is no teaching or suggestion that a 
second query that is transmitted is based on information from a reference table or on a 
list of reported events. 

Turning to paragraph 264 in Felsher which was cited in the Office Action as 
teaching that a second query is generated, that paragraph only teaches that a single 
query is transmitted from a recipient (i.e., from the application that generates the query) 
to the custodian medical records system (see lines 6-9). Here, there is no second 
query, only a first. As explained above, to the extent that the custodian medical record 
system has to access required data through an index to another database or a specific 
storage location, that indexed access is not a second query and instead is simply use of 
a direct pointer to the location where the required data is stored. 

Thus, Morange and Felsher fail to teach or suggest several claim 1 limitations. 

Turning to Smithies, Smithies fails to teach or suggest what the other references 
lack. First, while Smithies appears to contemplate a system including a database 12 
(see Fig. 1 ) that stores a list of different patient identifiers for a specific patient, Smithies 
fails to teach or suggest a reference table like the one in claim 1 that includes both a list 
of applications and associated patient identifiers. In this regard, Smithies teaches a 
system wherein a signature verification service is provided to multiple applications via a 
network (see abstract and Fig. 1 generally). To accomplish this task, Smithies teaches 
that database 12 is provided where model information indicative of a user's signature is 
stored. When an application employs the verification service a first time, the application 
transmits a message to the service indicating that the service is required where the 
message includes (1 ) information that can be used to uniquely identify a person whose 
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signature is to be authenticated (see col. 8, lines 50 and 53) and (2) a signature of the 
person to be authenticated (or information derived from the signature for comparison to 
the model signature information). Once the system identifies the identity of the person, 
the person's stored signature information is retrieved and compared to the signature 
information received from the application. Where the signature information matches 
within a threshold, the signature is authenticated. 

In addition, once a match occurs between signature information, the application 
generates an application unique patient identifier (AUID) (see col. 18, lines 42-44) and 
provides that unique identifier to the database 12 during a registration process. The 
unique patient identifier forms the basis for a new record for the person and is 
associated with the signature and is cross linked with other records for the person that 
were generated by other applications (see col. 18, lines 52-56). Thereafter, when the 
application wants to subsequently authenticate the same person's signature, the 
application need only transmit the AUID to the database which can then be used by the 
database to retrieve the signature information for the person (see col. 18, lines 49-51 ). 

In the above description, while the database may in fact store a list of person IDs 
used by different applications to reference a single person, there is absolutely no reason 
why such a database also has to include a list of applications associated with the 
person IDs. Consistent with this understanding Applicant has examined Smithies in 
detail and there is no teaching that a list of applications is stored along with the person 
identifiers. 

Second, like Morange and Felsher, Smithies fails to teach or suggest responding 
to an inquiry from a first application by transmitting a query to a second application 
based on information in the reference table (i.e., based on the application list and 
associated or corresponding patient identifiers in the table). In fact, because Smithies 
only teaches that a list of patient IDs are stored and not a list of associated applications, 
Smithies cannot teach a way to generate a second query to a second application based 
on information in the reference table. In short, because Smithies fails to teach or 
suggest an application list, there is no way for Smithies to determine which patient ID 
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numbers are associated with which applications if a second query were to be 
generated. 

For at least these reasons Applicant believes claim 1 and claims that depend 
there from are non-obvious over the cited references and requests that the current 
rejection be overturned. 

Claims 5-8 and 14-20 were rejected under 35 USC § 103(a) as being 
unpatentable over Morange (US patent application No. 2005/0102374) in view of 
Felsher (US patent application No. 2002/0010679) and further in view of Smithies 
(US patent No. 5,544,255). 

Each of claims 5, 14, 18, 19 and 20 requires limitations similar to the limitations 
described above with respect to claim 1 and each is believed to be non-obvious for 
essentially the same reasons described above with respect to claim 1 . 

For at least the above reasons Applicant believes each of claims 1 , 5, 14, 18, 19 
and 20 recites patentable subject matter and respectfully requests that the current 
rejections be overturned. 
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CONCLUSION 



In view of the above, Appellant requests reversal of the final rejection regarding 
claims 1-8 and 14-20 and a Notice of Allowance. 



Respectfully submitted, 



CARL DVORAK 



Dated: July 16, 2009 




Michael A. Jaskolski 

djstration No. 37,551 
Suarles & Brady LLP 
41 1 E. Wisconsin Avenue 
Milwaukee, Wl 53202-4497 
(414) 277-5705 
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VIII. CLAIMS APPENDIX 

(Patent Application No. 10/052,659) 

1 . In a system for distributed computing in a health care environment in 
which multiple different applications are in use connected on a common computer 
network, the improvement comprising 

a clinical exchange server on the network, the clinical exchange server including 
memory, the clinical exchange server programmed (i) to maintain a patient identification 
cross reference table, the patient identification cross reference table including a list of 
applications on the network and patient identification numbers used by each application 
wherein the patient identification numbers used by the applications are application 
distinct patient identification numbers for the patient, wherein the application distinct 
patient identification numbers for the patient include a first patient identification number 
used by a first application and a second patient identification number used by a second 
application where the second patient identification number is different than the first 
patient identification number, (ii) to maintain a list of events reported to it by other 
applications on the network and (iii) to respond to inquiries from a first application about 
an event recorded by a second application by transmitting a query to the second 
application based on the information in the reference table and the list of reported 
events. 

2. The system as claimed in claim 1 wherein the clinical exchange server 
also maintains an abstract about the events sent to it to facilitate exchange of 
information between the applications. 

3. The system as claimed in claim 1 wherein the reference table includes a 
master patient index identification code assigned to the patient as well as an application 
specific identification number assigned to the patient by each application. 

QB\8282042.1 



Carl Dvorak 

Serial No.: 10/052,659 
APPEAL BRIEF 
Page 1 1 

4. The system as claimed in claim 1 wherein the clinical exchange server 
also stores health insurance information about each patient so that such health 
insurance information can easily be accessed by any of the applications. 

5. A computer network for operation by a healthcare delivery enterprise, the 
network including a plurality of servers operating a plurality of application programs, the 
network comprising 

a clinical exchange server including a storage device, the clinical exchange 
server programmed to store in the storage device a reference table, the reference table 
including a master patient identifier for each patient, a list of application programs, and 
any separate identifying code used for the patient by any of the application programs 
wherein the identifying codes are application specific patient identifying codes for the 
patient, wherein the application specific patient identifying codes for the patient include 
a first patient identifying code used by a first application and a second patient identifying 
code used by a second application where the second patient identifying code is different 
than the first patient identifying code, so that the identifying code used by an application 
for a patient can be found by accessing the reference table, the clinical exchange server 
further programmed to facilitate information exchange between the applications by 
using the reference table to extract information from an application requested by 
another application. 

6. The computer network of claim 5 wherein the clinical exchange server 
also maintains a table of events associated with patients, the table of events including 
identifying information about the events and the identification of the application holding 
information about the event. 

7. The computer network of claim 6 wherein the event table also includes an 
abstract about each of the events. 
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8. The computer network of claim 5 wherein the clinical exchange server 
also maintain health insurance information about the patient that can be access by 
another application. 

9-13. (Cancelled). 

1 4. A method for use with a system for distributed computing in a health care 
environment in which multiple different applications are in use connected on a common 
computer network, the method comprising the steps of: 

providing a clinical exchange server on the network, the clinical exchange server 
including memory in which a reference table and a list of events are maintained where 
the reference table includes a list of applications on the network and patient 
identification numbers used by each application wherein the patient identification 
numbers used by the applications are application distinct patient identification numbers 
for the patient, wherein the application distinct patient identification numbers for the 
patient include a first patient identification number used by a first application and a 
second patient identification number used by a second application where the second 
patient identification number is different than the first patient identification number, the 
list of events including a list of events reported to the clinical exchange server by other 
applications on the network; 

when an inquiry is received from a first application about an event recorded by a 
second application, the clinical exchange server transmitting a query to the second 
application based on the information in the reference table and the list of reported 
events. 

1 5. The method of claim 14 wherein the step of providing a clinical exchange 
server includes providing a clinical exchange server that also maintains an abstract 
about each event sent to the clinical exchange server to facilitate exchange of 
information between the applications. 
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16. The method of claim 14 wherein the reference table includes a master 
patient index identification code assigned to the patient as well as an application 
specific identification number assigned to the patient by each application. 

1 7. The method of claim 1 4 wherein the step of providing a clinical exchange 
server includes providing a clinical exchange server that also stores health insurance 
information about each patient so that such health insurance information can easily be 
accessed by any of the applications. 
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1 8. A method for use with a computer network for operation by a healthcare 
delivery enterprise, the network including a plurality of servers operating a plurality of 
application programs, the method comprising the steps of: 

providing a clinical exchange server including a storage device, the clinical 
exchange server programmed to store in the storage device a reference table, the 
reference including a master patient identifier for each patient, a list of application 
programs, and any separate identifying code used for the patient by any of the 
application programs wherein the identifying codes are application specific identifying 
codes for the patient, wherein the application specific patient identifying codes for the 
patient include a first patient identifying code used by a first application and a second 
patient identifying code used by a second application where the second patient 
identifying code is different than the first patient identifying code, so that the identifying 
code used by an application for a patient can be found by accessing the reference table; 

programming the clinical exchange server to facilitate information exchange 
between the applications by using the reference table to extract information from an 
application requested by another application. 
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1 9. A system for distributed computing in a health care environment, the 
system comprising: a computer network; 

a first application run on the network that uses a first patient identification number 
to reference a first patient; 

a second application run on the network that uses a second patient identification 
number to reference the first patient where the second patient identification number is 
different than the first patient identification number; 

a clinical exchange server on the network, the clinical exchange server including 
memory, the clinical exchange server programmed (i) to maintain a patient identification 
cross reference table, the patient identification cross reference table including a list of 
applications on the network including the first and second applications and patient 
identification numbers used by each application including the first and second patient 
identification numbers for the first patient, (ii) to maintain a list of events reported to it by 
other applications on the network and (iii) to respond to inquiries from the first 
application about an event recorded by the second application by transmitting a query to 
the second application based on the information in the reference table and the list of 
reported events. 
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20. A system for distributed computing in a health care environment, the 
system comprising: 

a computer network; 

a first application run on the network that uses a first patient identification number 
to reference a first patient; 

a second application run on the network that uses a second patient identification 
number to reference the first patient where the second patient identification number is 
different than the first patient identification number; 

a clinical exchange server on the network, the clinical exchange server including 
memory, the clinical exchange server programmed (i) to maintain a patient identification 
cross reference table, the patient identification cross reference table including a list of 
applications on the network including the first and second applications and patient 
identification numbers used by each application including the first and second patient 
identification numbers for the first patient and (ii) to respond to inquiries from the first 
application about an event recorded by the second application by transmitting a query to 
the second application based on the information in the reference table. 



QB\8282042.1 



Carl Dvorak 

Serial No.: 10/052,659 
APPEAL BRIEF 
Page 17 

IX. EVIDENCE APPENDIX 



There is no evidence, other than the documents cited in the final Office Action. 
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X. RELATED PROCEEDINGS APPENDIX 



There are no decisions in related proceedings. 



QB\8282042.1 



